Skip to main content
Feedback

Overview and key concepts

A policy template is a named, reusable group of one or more API policy rules that you can assign to multiple deployed APIs at once. Instead of configuring policies individually on each API, you define the template once and apply it wherever consistent enforcement is needed.

Policy templates support a "Template-First" deployment model. Templates are discoverable by the Automated Control Plane (ACP), which can automatically apply governance rules to APIs during deployment without requiring manual policy configuration on each API.

Prerequisites

  • You must have the API Management Access (API_MGMT_ACCESS) role and at least one of the following permissions: API Management Read/Write (API_MGMT_API_READ_WRITE) or API Management Read (API_MGMT_API_READ).
  • To create, edit, or delete templates, you need API Management Read/Write (API_MGMT_API_READ_WRITE).
  • At least one policy rule must already exist in your account before you can create a policy template. Templates reference existing policy rules; they do not create new ones. Policy rules are configured independently using the existing policy rule mechanisms.
  • Policy templates can only be assigned to APIs that are deployed on a Boomi API Gateway. Assigning a template to a non-Gateway deployed API has no effect.

Key concepts

Policy template — A named collection of one or more policy rules (request or response) along with metadata such as name and description. You create a template once and can assign it to many APIs across multiple environments, ensuring consistent policy enforcement.

Template status — Each template is shown with a status reflecting its current state. A template marked Latest is the most recent version. A template marked Active is currently assigned to one or more APIs. A template marked Deprecated has been superseded by a newer version and is no longer recommended for new assignments.

Template version — Each time you edit a template that is already assigned to one or more APIs, the system automatically creates a new version rather than modifying the existing one. This ensures that APIs using the current version are not disrupted. Version numbers increment as integers (1, 2, 3, ...).

Template correlation ID — An internal identifier that stays the same across all versions of a single template. It links version 1, version 2, and so on back to the same original template definition, enabling retrieval of all versions via the GraphQL API.

Execution timing (appliedWhen) — Controls when the policy rules in a template run relative to standard policies on the API. Each rule group in a template has its own execution timing, set from a dropdown on the Create or Edit form. Available options are: Before Request And Before Standard Policies, Before Request And After Standard Policies, After Response and Before Standard Policies, and After Response and After Standard Policies. Changing the execution timing on a rule within a template overrides the rule's own individual timing setting.

Template assignment — The act of attaching one or more templates to a deployed API at a specific path. Once assigned, the policies defined in each template are applied to that API's execution. Multiple templates can be assigned to the same API; their rules are combined and executed based on the configured order and the request/response context of each rule group.

Template-First deployment — A governance model in which templates are created and governed centrally by platform or security experts, and the Automated Control Plane (ACP) automatically discovers and assigns templates to APIs during deployment. This abstracts policy configuration away from individual API teams.

Attachment state — The UI displays a message indicating whether a template is unused, assigned to APIs but not yet deployed to a Gateway, or actively enforced on live traffic.

For a full description of all fields and their valid values, refer to Configuration reference.

How policies from multiple templates execute

When multiple templates are assigned to the same API, their policy rules are combined into a single execution sequence. The combined order is determined by:

  1. The order in which templates are assigned to the API.
  2. The execution timing (appliedWhen) of each rule group within each template — rule groups configured to run before the request are executed before those configured to run after the request or on the response.
  3. The order of rules within each rule group, as configured at template creation time.

Rules from different templates do not conflict with each other at the data model level — they are sequenced and applied independently.

On this Page